To provide consistent, high performance client support, businesses typically rely on either fault tolerant or high availability systems. Fault tolerant systems typically include two distinct yet identical processing paths. Each processing path operates on an identical instruction stream in lock-step. In the event of a fault in one of the processing paths, the redundant path provides seamless failover support to the client.
One problem with fault tolerant systems is that they are relatively expensive for the received performance. Each processing path may include many components, and the cost of replicating the components in the redundant path provides increased cost and size with no gain in processing performance. An alternative to the fault tolerant systems are high availability systems. High availability systems are designed with some level of redundancy in order to provide fault tolerance for single points of failure. High availability systems differ from full fault tolerant systems in that not every component is duplicated, and generally the processing paths, while operating in parallel, operate on their own instruction streams. Thus, when both of the processing paths are operational, the entire processing capacity of the system can be realized. In the event of a fault in one of the paths, the other path remains operable, and the system can remain available while that path is repaired. Thus, high-availability systems help to strike a balance between system cost/performance and system reliability.
However, in both fault tolerant and high-availability systems, it is inevitable that there will be some point of failure in the system. As stated above, when this occurs, the failed device must be fixed. For example, a networked storage device may include a number of disks coupled to a pair of processing modules via a midplane. In the event that one of the components coupled to the midplane should fail, the component is swapped out. In high-availability systems, because other redundant components are provided, the swap may be relatively invisible to the user.
However, the swap is not truly invisible. In many typical processing systems, each component of the system includes a distinct serial number, and other data identifying, for example, a type of the component, date of manufacture or the like. For the purpose of this application, such data shall be called ‘component characteristic’ data. When one device is exchanged for another device, the serial number, type of device, and potentially the system configuration could be altered.
Thus, in order for the processing system to be managed correctly, it is important that a system controller keeps track of the characteristics of the components that comprise the system. For example, in the networked storage system described above, it is important to know the characteristics (such as serial number, type, etc.) of the components (disk devices, processor devices or line cards) coupled to the mid-plane connector. The characteristic data is important from the standpoint of overall system control, as it allows the system controller to appropriately manage the data flow within the system. It is also important for the purposes of support; in the event that there is a failure in the component, it is important to be able to identify that component so that the correct support routines (diagnostics, etc.) can be executed. In addition, it is important should the networked storage device be coupled into an external network. For example, a World Wide Name (WWN) seed is used in a Fibre Channel protocol to provide a unique World Wide Name for a given device coupled into a network. Should the WWN seed be unavailable, the network identity of the system could be lost.
In usual practice, the component characteristic data is maintained manually by the system administrator. When the network device is received, the characteristic data is recorded and stored on one of the devices, or in an external notebook. A problem exists, though, if one or more of the components coupled to the system are swapped out and the stored characteristic data is not updated. Such events happen regularly in the support environment and, as a result, often there is not an up-to-date record of the characteristics of the components that comprise the system. Such inconsistencies could cause problems with network connections and additionally in obtaining the proper system support. It would be desirable to identify an improved method for maintaining component information in a system.